Hypertext and its equivalents have become commonplace in computer documents. A hypertext item is an item that can be used to access additional documents or other computer objects. For example, in a document that addresses radio communications, Marconi's name may appear highlighted on the computer display, the highlighting indicating that Marconi's name is a hypertext item. If the reader of the document selects the highlighted text, Marconi's biography may appear on the display. Similarly, hyperlinks may display Marconi's image, or perhaps a video or audio clip.
Hypertext is implemented by associating a reference locator to the hypertext item. When the hypertext item is selected, the object that is located at the location indicated by the reference locator is displayed or executed. That is, in general, the reference locator may point to another document, an image file, etc. or it may point to a program that plays the video clip. The reference locator is commonly termed a “Universal Resource Locator” (“URL”), and the programming language used to embed hypertext and the associated URLs into a document is termed the “HyperText Markup Language” (“HTML”). A typical example of a hypertext entry is:                The invention of <A HREF=“gifs/radio.gif”>radio </A> is credited to <A HREF=“http://www.encyclopedia.com/inventors/marconi.htl”> Marconi </A>.The “<A>” and “</A>” entries define the beginning and end of the hypertext entry. This example shows two hypertext entries, one for “radio” and one for “Marconi”. The “HREF=” entries define the URL associated with each of the hypertext entries. Because the words radio and Marconi are contained within the hypertext bounds, they will be displayed by an HTML processing program as highlighted text. The URLs are not displayed. When a user selects the text “Marconi”, the program will open the file that is named “marconi.htl” that is located in the file directory “inventors” on the machine named “www.encyclopedia.com” on the world wide web (“http://”). When the user selects “radio” the program will open the file named “radio.gif” in the file directory “gifs” within the current file directory of the current machine. That is, because the URL associated with “radio” does not specify a particular machine name, the specified file name is relative to the location of the document being processed. Conversely, the address associated with “Marconi” is absolute, and independent of the location of the document that contains this reference.        
The use of absolute references allows the document containing the references to be located anywhere and still provide access to the referenced URL. It requires, however, that the absolute reference be known and specified at the time the document is created. Relative addressing, on the other hand, allows the reference locators to be dynamically determined, based upon the location of the document. If the document is a part of a large suite of documents and objects, relative addressing is typically preferred, because it allows the suite of documents and objects to be located on different machines without modification of the reference locators. That is, for example, if the above example document is always located in a file directory that includes a file sub-directory named “gifs” that contains the object “radio.gif”, the above HTML example for the “radio” hypertext will operate properly regardless of where the file directory that contains the document and “gifs” is located, and does not require an a priori absolute reference to “radio.gif”. That is, “radio.gif” can be relocated as required, without requiring a modification to the HTML reference, provided that it maintains the same file directory relationship with the document. Conversely, if the file “marconi.htl” is relocated, all documents that contain an absolute reference to this file must be modified.
Further compounding the problems associated with reference locators is that the author of an HTML document typically authors the document on one computer system, while the viewing, or browsing, of the document is intended for a different computer system. Relative reference locators, for example, require that the file structure of the destination computer system be the same as that of the authoring computer system. That is, in the “radio” example, both the authoring system and the destination system must be configured such that the file “radio.gif” is within a directory called “gifs” that is in the same directory as the document. Often, however, a file structure suitable for authoring a document is an inefficient file structure for reading or browsing documents. A general purpose authoring system, for example, may be structured to have a directory called “pictures” that contains directories “gifs”, “avi” and “mpg”, corresponding to different forms of images that may be included in an authored document. The “gifs” directory may contain directories “people”, “places”, and “things”, corresponding to the different types of “gifs” available, in terms of content. The file “radio.gif” may be located, for example, within the directory “pictures/gifs/things”. Such a structure allows an author to pick and choose from a variety of objects for inclusion in a particular hypertext document. The destination system, on the other hand, may be a commercial web service machine, and a storage fee may be charged that is dependent upon the number of objects stored on the machine, or the number of file directories utilized. In this case, it would be inefficient and costly to copy the entire directory structure of the authoring system onto the commercial web service machine. To ease the migration of the authored system to a destination system, the author may structure a file system that conforms to the intended destination system and transfer each object that is referenced into this file structure. This approach, however, virtually elimiates the ease of use provided by the general purpose authoring file structure. To ease the authoring task, on the other hand, the author may use the general purpose authoring file structure, but thereafter be required to modify each hypertext documents to conform to the destination file structure and also transfer each of the referenced objects and files from the authoring system to the destination file structure. In either case, the movement of hypertext documents is problematic, due to the use of URLs in the conventional manner.
The MIME format has been developed to facilitate the transfer of hypertext documents. In accordance with the MIME format, when a reference locator is found in a document, the object that corresponds to the reference locator is encoded and embedded directly into the document. The resultant document can become significantly large, and requires a subsequent MIME decoding upon receipt into a format compatible for viewing. Although the MIME format is robust, the encoding and decoding process introduces additional overhead processing costs and time, and may not necessarily be compatible with all current and future forms of information transfer.
Therefore, a need exists for a method and apparatus for relocating hypertext documents that efficiently and effectively makes the adjustments required for both relative and absolute reference locators in the hypertext document. A need also exists for a method and apparatus for relocating the objects that are referenced in a relocated hypertext document, so as to correspond to the adjusted relative and absolute reference locators in the relocated hypertext document. A need also exists for a method and apparatus that provides for the transfer of hypertext documents and referenced objects with minimal intermediate processing or encoding.